Subject: Loop Prevention - Brain Dump...

From: "Shannon Nix" <[email-masked]>
Date: Thu, 19 Aug 93 15:59:36 EST

Choon,

DISCLAIMER: I am a bridging novice!  However...here goes:

I believe we must really solve two problems:

  1)  Loop prevention.  
  2)  Duplicate frames.

It seems that since we named the siglet after the former problem, that the 
latter has been ignored. How about: 

  [email-masked]

Just kidding..back to the issues:

In SRB: if the DLSW cloud is a virtual ring with a commonly administered 
ring number, then I believe both problems are addressed.

Transparent LAN segments adjacent to the DLSW cloud reintroduces the first
problem, loops.

AND

Parallel transparent forwarders - A DLSW combined with either another DLSW 
or pure transparent bridge providing parallel connectivity between a 
common adjacent transparent LAN segment and at least one other common LAN 
segment -  reintroduces the second problem, duplicate frames.

IF the only problem we were trying to solve were loop prevention - 
preventing broadcast traffic from traversing a DLSW cloud multiple times -, 
then I would propose the following:

   1)  We have a commonly administered virtual ring number for the DLSW 
       cloud for SRB ( this could be verified at capabilities exchange).

   2)  ROUTE EXPLORATION traverses the DLSW cloud as a CANUREACH.  

   3)  When ROUTE EXPLORATION exits the cloud, it is put onto the 
       a local LAN segment as a TEST frame.  

   4)  TEST frames can carry a field for data ( arbitrary user data 
       which should be echoed back in the TEST RSP).

   5)  Let's maintain a list of virtual ring, or cloud, numbers for the 
       DLSW clouds an exploration has traversed (just like a RIF!)

   6)  If you receive a TEST containing your virtual DLSW cloud number then
       discard it.

   7)  The CANUREACH must be enhanced to carry the virtual DLSW cloud
       list. This must be a list because DLSW clouds will be organized in
       "clusters" to get around the scalability issues.

   WHAT ABOUT NETBIOS!!!!:

    2) ROUTE EXPLORATION traverses the DLSW cloud as a NETBIOS_NQ.

    3)  When ROUTE EXPLORATION exits the cloud, it is put onto the 
        a local LAN segment as a Name Query.

    4)  If Name Recognized comes back THEN...

    5)  Test for reentry into your DLSw cloud BY...
  
    6)  Sending a TEST (with your virtual DLSW cloud number) to the station 
        which responded with the Name Recognized.

    7)  No TEST RSP means that your DLSW cloud must be reentered to reach 
        that station.  Therefore don't send back the NETBIOS_NR.

IF, HOWEVER, we are trying to solve both problems: loops and duplicate 
frames,... now there's a problem!

I believe the solution is Spanning Tree:

    1) From the perspective of a station on a transparent LAN segment, a
       DLSW should be just another spanning tree bridge - albeit a Spanning 
       Tree bridge that filters all traffic except SNA and NetBIOS.

    2) The DLSW cloud is simply a virtual LAN segment shared by
       all its constituent DLSWs.

    3) Each DLSW node which supports an adjacent transparent LAN 
       segment should implement the 802.1(d) bridging algorithms (many 
       vendors already have this).  

    4) From the perspective of the ST bridge, the DLSW component is 
       just another a bridge port (attached to the virtual LAN 
       segment which is really a DLSW cloud)  That bridge port has a 
       state just like any other bridge port (ie. Learning, 
       Listening, Blocked,...)

    6) "Path Costs" can be administered to achieve the desired preference
       between Data Link Switching and Pure ST Bridging.

NOW THE HARD PART:

    If it is desirable for:

    1) SNA or NETBIOS traffic from an adjacent transparent LAN segment
       to reach a destination LAN segment VIA Data Link Switching

       WHILE CONCURRENTLY

    2) Bridging traffic which is neither SNA or NetBIOS between the 
       same two LAN segments

       THEN WE GOT A PROBLEM!

    Only one solution has occurred to me so far:

    Allowing encapsulation of bridged traffic across a DLSW cloud. Ouch! 
    There goes the neighborhood!

    1)  A DLSW could establish a distinct DLSW circuit, as needed, for 
        encapsulating transparently bridged traffic between any two MAC 
        pairs (use some funky SAPs to identify the circuit). Flow         
        control should be exerted, on a per-circuit basis, to "push back" 
        the function of discarding of excess frames to the 
        originating interface. 

    2)  I would think support of transparent bridging pass-thru would 
        certainly be an option set rather than a base DLSW function.

Rgds, Shannon
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

---

From: Choon Lee <[email-masked]>
Date: Fri, 20 Aug 1993 12:31:19 -0700

Shannon,

Good of you to identify and split the problem set between loops and duplicate
frames. I guess we can tolerate either of them to some extend, e.g., if the loop
does not become an infinite one (can that happen?), it's OK. Also, if the duplicate
frames are confined to TEST frames (maybe even XID frames), that's also OK.

What I hope to see this group achieve is to be able to :
(1) Able to support parallel DLSw between 2 LANs 
	(i) A has a DLSw to B, C has a DLSw to D, A and B on one LAN, 
	    C and D on the other LAN.
	(ii) A has a DLSw to B, C has a DLSw to B also, A snd C on one LAN.

    The ability to provide redundant DLSw path, IMHO, provide a very useful
    feature to the customers. (To configure manually that DLSw link C-D is
    unusable, and when A-B goes down, configure C-D usable, again manually, 
    is unacceptable - this is too easy!)
    So, as long as a scheme allows two end stations on both LANs to have a session
    in that topology, then that's what we want.

(2) If we can also have the ability to support a DLSw path in parallel to a 
    bridged path, that will be wonderful. However, unless we can have a simple
    solution to this problem, I think maybe no customer would intentionally have
    this configuration (if I can get from LAN A to LAN B bridging, why go through
    all the trouble of doing IP tunneling?). But still it would be nice to be able
    to at least detect this case (of course, the two end station would not talk to
    each other!).

(3) While we have this wonderful scheme, let's make sure that it doesn't break the
    other topology.

Shannon, I still have this doubt about using spanning tree. I think we cannot assume
that we can always convert the WAN links into a "LAN". If not for this, I would
definitely go with spanning tree.

>>   [email-masked]
too late for this now.

>>        "clusters" to get around the scalability issues.
I like this! With this scheme extended, I think we can achieve goal #1 (support
parallel DLSw paths). If we were to add also a tie-breaking element (maybe the IP
address) to the TEST frame, then when the DLSw receives a TEST frame with that 
virtual ring number in the data field, it knows that the TEST frame has gone 
through the DLSw switch before. With the IP address, it can decide whether it or
the other DLSw should respond with the ICANREACH when it gets the TEST response.

Do you think this would work? 

And for goal #2 (parallel DLSw and bridged path), if a DLSw node receives a TEST
frame that does not have the virtual ring number (frames going through the bridged
path won't), but has the same 3-tuple (SA,DA,SSAP) as a CANUREACH, then it can
again not respond with ICANREACH when a TEST response comes back.

Hey, this may work! I'm excited! 
BUT, do you think that it's OK that the TEST frame that's sent out to be different
(now contains different data) from being received? That shouldn't break anyone out
there, right? From RFC1434, it seems like XID flow happens after the DLSw has gone
into circuit established state. So we're now in fat city.

>>        Tree bridge that filters all traffic except SNA and NetBIOS.
I think forcing spanning tree on DLSw is like forcing a round peg through a square
hole. There are two things that a spanning tree path would differ from a DLSw
path:
(1) You pointed out the first one, which is that a spanning tree path would allow
all bridged traffic to flow, while a DLSw path allows only LLC2 and Netbios traffic.
As such, they are not equal, and given a choice of which one to block, always block
the DLSw path! You suggested that we can try to encapsulate non-LLC2 and non-Netbios
traffic, and I can guess how everyone likes that! :-)

(2) DLSw does not do cascade. We cannot have a frame going A-B-C if A-B and B-C
are DLSw paths. This, to me, is the one that make spanning tree unsuitable for
DLSw. Imagine that spnning tree tells us that we can get from A to C, but in actualty
(DLSw) we can't!

>>        all its constituent DLSWs.
My doubt about converting a DLSw cloud into a virtual LAN segment. Does this work in
all cases?